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ABSTRACT 

The  current  generation  Battlespace  Communications  System  (Land)  for  voice 
(telephony)  is  based  on  a  military  standard  circuit  switching  technology.  There  has 
been  considerable  discussion  on  alternatives  based  on  packetised  voice,  ie  voice  over 
Internet  Protocol  and  voice  over  ATM.  This  paper  examines  these  two  options  and 
considers  the  bandwidth  demands  of  each  option,  specifically  in  the  context  of  an 
agreed  reference  model  of  the  network  including  traffic  load.  This  report  is  preliminary 
work  prior  to  the  combination  of  this  voice  model  with  that  of  an  agreed  data 
workload  and  examination  through  simulation  of  consequent  integrated  network 
performance. 
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Executive  Summary 

The  Australian  Defence  Force  has  been  procuring  under  Project  Parakeet  a  digital 
communications  network  for  use  by  forces  deployed  to  the  land  battlefield.  It  employs 
a  military  standard  circuit  switching  technology  and  is  effectively  a  militarised 
narrowband  ISDN  system.  The  current  phase  of  Parakeet  has  recognised  the 
limitations  of  the  circuit  switching  technology  in  carr5dng  computer  data 
commvmications.  Accordingly,  a  concept  demonstrator  element  has  been  added  to  the 
current  phase  that  will  field  a  limited  number  of  Asynchronous  Transfer  Mode  (ATM) 
switches  along  with  an  Internet  Protocol  (IP)  capability  which  will  explore  the  carriage 
of  multimedia  services  over  Parakeet.  As  a  parallel  activity,  effort  is  being  expended  to 
make  a  comparative  performance  study  between  the  two  technologies,  ATM  and  IP, 
for  delivering  multimedia  traffic  (voice,  data  and  possibly  video  in  the  future). 

This  paper  examines  the  two  options  of  Voice  over  IP  (VoIP)  and  Voice  Telephony 
over  ATM  (VTOA)  and  considers  the  bandwidth  demands  of  each  option,  specifically 
in  the  context  of  an  agreed  reference  model  of  the  network  including  voice  traffic  load. 
The  study  found  that  a  simplistic  VoIP  approach  would  be  extremely  wasteful  of  the 
limited  bandwidth.  Any  use  of  IP  as  a  total  WAN  solution  for  voice  services  must 
implement  protocol  header  compression  to  be  feasible  in  the  tactical  domain.  The 
average  bandwidth  demands  used  by  the  voice  system  during  the  busy  hour  on  the 
busiest  trunk  link  indicate  that  VTOA  and  VoIP  with  packet  header  compression  are 
certainly  promising  solutions  and  more  than  twice  as  efficient  as  standard  VoIP. 
Regardless  of  which  approach  is  adopted,  significant  capacity  can  be  released  for  non- 
real  time  communications. 

This  report  is  intended  to  be  preliminary  work  prior  to  the  combination  of  this  voice 
model  with  that  of  an  agreed  data  workload  and  examination  through  simulation  of 
consequent  integrated  network  performance.  The  findings  of  this  report  justify  the 
continuation  of  the  analysis  to  the  next  stage.  The  final  outcome  to  Defence  will 
provide  significant  input  into  the  feasibility  of  including  civil  technologies  into  the 
technical  architecture  of  a  future  Battlespace  Communications  System  (Land). 
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1.  Introduction 

The  Australian  Defence  Force  has  been  procuring  under  Project  Parakeet  a  digital 
communications  network  for  use  by  forces  deployed  to  the  land  battlefield.  The  system 
uses  various  transmission  systems  to  provide  voice  and  data  services  between 
headquarters.  It  employs  a  military  standard  circuit  switching  technology  and  is 
effectively  a  militarised  narrowband  ISDN  system.  In  circuit  switching  technology 
necessary  resources  such  as  bearer  channels  are  allocated  by  the  network  for  the 
duration  of  the  phone  call.  By  contrast,  more  modem  data  communications  systems 
transport  data  in  segments  (packets  or  cells)  which  are  routed  around  the  network 
consuming  resources  in  a  more  flexible  and  responsive  manner. 

The  current  phase  of  Parakeet  has  recognised  the  limitations  of  the  circuit  switching 
technology  in  carrying  computer  data  communications.  Accordingly,  a  concept 
demonstrator  element  has  been  added  to  the  current  phase  that  will  field  a  limited 
number  of  Asynchronous  Transfer  Mode  (ATM)  switches  along  with  an  Internet 
Protocol  (IP)  capability.  This  concept  demonstrator  will  be  trialed  and  assessed  in  the 
context  of  developing  the  next  generation  of  battlespace  (land)  communications 
systems.  As  a  parallel  activity,  effort  is  being  expended  to  make  a  comparative 
performance  study  between  the  two  technologies,  ATM  and  IP  for  delivering 
multimedia  traffic  (voice,  data  and  possibly  video  in  the  future). 

This  report  will  first  highlight  its  scope  in  relation  to  current  studies  into  the 
Battlespace  (Land)  Communications  Architecture.  We  will  then  review  some 
background  material  on  the  multimedia  communications  standard  H.323  for  IP  based 
networks  specifically  in  the  context  of  Voice  over  IP  (VoIP).  A  similar  review  will  be 
carried  out  on  the  AAL-2  standard  for  Voice  Telephony  over  ATM  (VTOA).  Section  4 
will  calculate  the  bandwidth  characteristics  of  VoIP  and  VTOA  examining  the  network 
demands  as  a  function  of  the  number  of  voice  calls  being  carried  on  a  trunk.  Section  5 
will  discuss  signalling  aspects  of  VoIP  and  VTOA.  The  endorsed  Parakeet  reference 
network  will  be  introduced  in  Section  6  that  will  form  the  basis  for  determining  the 
voice  traffic  load.  Section  7  will  combine  the  results  of  the  traffic  analysis  and  the 
bandwidth  characterisation  to  deduce  the  peak  and  average  network  loads  from  the 
alternative  approaches. 

2.  The  Land  Battlespace  Communication  Studies 

There  are  a  number  of  studies  currently  being  conducted  in  the  area  of  battlespace 
(land)  communications.  An  overarching  architectural  study  [1]  is  being  conducted  by 
collaboration  between  University  College  (University  of  NSW  at  the  Australian 
Defence  Force  Academy)  and  DSTO.  The  aim  of  this  work  is  to  develop  an  operational 
concept  description  of  the  Battlespace  (Land)  Communications  System  to  help  shape 
the  development  of  a  Project  Definition  Study  (PDS)  under  Project  Parakeet  and  its 
follow  on  project  xmder  Joint  Project  2072  (JP-2072). 

The  PDS  will  receive  input  from  trials  of  the  ATM  and  IP  concept  demonstrator 
being  developed  as  part  of  phase  6  Project  Parakeet.  As  a  separate  initiative,  an 
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unsolicited  proposal  from  the  communications  consultant  company  Codarra  for  an 
examination  of  a  totally  IP  based  land  battlespace  communications  system  led  DSTO  to 
undertake  work  with  a  prime  focus  on  quantitative  assessment  of  the  IP  WAN  option. 

This  report  will  provide  input  to  the  study  in  respect  of  the  voice  network  load. 
Once  an  agreed  data  traffic  model  is  endorsed,  this  will  be  combined  with  the  voice 
model  to  examine  through  simulation  the  consequent  integrated  network  performance 
network.  Performance  parameters  such  as  congestion,  latency  and  latency  variation 
will  be  particularly  examined  in  the  context  of  real  time  services  such  as  voice. 

3.  VoIP  and  VTOA  Standards 


3.1  Overview 

IP  is  the  fundamental  xmderlying  protocol  used  on  the  world  wide  Internet.  The 
internet  protocol  suite  (usually  known  as  TCP/IP  from  Transmission  Control 
Protocol /Internet  Protocol)  has  been  developed  using  a  layered  approach  [2].  The  IP 
layer  provides  a  best  effort  service  to  get  data  packets  from  the  originating  host  to  the 
destination  host.  This  provides  the  internetworking  layer  upon  which  the  well-known 
Transport  Control  Protocol  (TCP)  layer  provides  a  reliable  end-to-end  coimection 
service.  Less  well  known  is  the  User  Datagram  protocol  (UDP).  This  protocol  operates 
at  the  same  layer  as  TCP,  however  provides  a  best  effort  datagram  service  over  IP, 
better  suited  for  the  exchange  of  real-time  information  which  would  rather  have  data 
discarded  than  suffer  excessive  time  delay.  Below  the  IP  layer  is  the  physical  layer, 
which  in  our  case  is  likely  to  be  the  Point  to  Point  Protocol  (PPP). 

ATM  is  quickly  becoming  a  popular  mechanism  to  provide  a  single  network 
capable  of  supporting  a  wide  range  of  services  with  a  particular  strength  in  its  ability  to 
support  a  guaranteed  quality  of  service  (QoS).  The  fundamental  concept  of  ATM 
revolves  around  the  transfer  of  information  in  small,  fixed  length  packets  called  cells. 
Since  ATM  uses  a  connection-oriented  service,  the  cell  headers  can  be  considerably 
smaller  than  IP  packets  and  avoid  the  header  overhead  from  becoming  too 
burdensome.  It  has  many  advantages  over  circuit  switching  the  most  important  of 
which  is,  like  IP  networks,  the  ability  to  conduct  dynamic  bandwidth  allocation. 
Several  data  sources  can  be  multiplexed  on  the  same  connection  in  a  flexible  fashion  to 
allow  users  to  obtain  bandwidth  on  demand.  To  provide  the  link  between  user 
applications  and  the  ATM  cell  layer,  a  number  of  alternative  protocols  forming  the 
ATM  Adaptation  layer  (AAL)  have  been  developed.  In  this  report,  we  will  consider 
real-time  voice  traffic  over  ATM  using  the  AAL-2  standard. 

There  are  two  fundamental  approaches  to  implementing  a  voice  service  over  a 
digital  WAN,  regardless  of  whether  an  IP  or  ATM  mechanism  is  being  employed.  The 
two  approaches  are  not  mutually  exclusive  and  can  co-exist  and  interconnect  through 
the  use  of  gateways. 

Individual  User  Interconnection.  For  this  option  each  connection  is  treated  totally 
independently  and  the  audio  bit  stream  is  passed  from  user  to  user  over  the  vmderlying 
data  switching  infrastructure  (IP  routers  or  ATM  switches).  Note  it  is  important  to 
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discriminate  between  the  switching  control  function  of  a  voice  switch/PABX  and  the 
actual  switching  process.  There  may  be  a  voice  network  controlling  service  on  the 
network  to  route  calls,  determine  availability  of  end  terminals  and  provide  value 
added  service  such  as  voice  mail/follow  me  etc.  However,  the  actual  connections  do 
not  pass  through  the  physical  controller  device. 

PABX  Interconnection.  Here  calls  from  subscribers  destined  for  the  WAN  are 
concentrated  into  one  point  in  a  local  area,  the  PABX.  The  interconnection  of  PABXs 
over  the  WAN  can  then  be  through  any  number  of  means,  for  the  purpose  of  this 
report  via  VoIP  or  VTOA.  PABX  interconnection  via  VoIP  is  typically  via  a  gateway  so, 
from  the  perspective  of  the  WAN,  the  connections  appear  to  be  individual  user 
interconnections.  Interconnection  of  PABXs  via  ATM  is  significantly  different  and  can 
occur  in  four  approaches: 

•  Each  PABX  interconnection  has  a  separate  physical  port  on  the  PABX.  The  port  is 
then  connected  to  an  ATM  switch  and  passes  over  a  logical  cormection  that  is 
transparently  carried  over  the  ATM  network  via  a  constant  bit  rate  Circuit 
Emulation  Service  (AAL-1).  The  other  end  of  the  interconnection  terminates  at  a 
fixed  port  on  a  specific  PABX.  Thus  the  ATM  network  is  merely  emulating  point-to- 
point  links  between  PABXs.  All  the  intelligence  is  vested  in  the  PABX  that  will 
typically  need  to  tandem  calls  to  route  connections  through  the  network. 

•  A  minor  variation  on  the  previous  approach  could  see  a  single  physical  connection 
between  the  PABX  and  the  ATM  switch  carrying  a  TDM  group.  Predetermined 
channels  on  the  group  are  connected  over  the  ATM  to  predetermined  PABXs. 
Functionally  this  is  the  same  as  the  first  option,  except  that  the  interconnections 
between  PABXs  will  have  a  fixed,  limited  number  of  channels,  and  all  the 
interconnections  emanating  from  a  particular  PABX  will  share  one  physical  TDM 
group  until  the  first  ATM  switch. 

•  The  next  stage  in  sophistication  sees  the  ATM  switch  monitor  the  signalling  on  the 
PABX  trunk  sufficiently  only  to  determine  which  TDM  channels  are  active,  pass 
active  channels  only  over  the  ATM  network,  and  recreate  the  complete  TDM  trunk 
at  the  distant  PABX.  When  using  AAL-1  this  is  known  as  the  Dynamic  Bandwidth 
Circuit  Emulation  Service.  The  same  approach  can  be  adopted  using  AAL-2 
(considered  to  be  the  "non-switched  trunking  mode"). 

•  The  previous  two  approaches  relied  on  the  PABX  to  determine  the  routing  of  calls. 
A  more  sophisticated  approach,  typically  using  AAL-2,  is  to  have  more  capable 
signalling  processing  in  the  interface  to  the  ATM  switch  -  the  interworking  facility 
(IWF).  In  effect  the  ATM  network  becomes  a  single  virtual  PABX.  The  entry  ATM 
switch  interprets  the  signalling  coming  from  the  PABX,  determines  the  exit  ATM 
switch  and  passes  the  voice  channel  stream  with  all  the  other  calls  for  that  exit 
ATM  switch  onto  the  ATM  circuit.  There  may  be  no  direct  connection  between 
entry  and  exit  ATM  switches,  but  the  composite  stream  remains  in  ATM  cells  until 
exiting  the  ATM  network.  This  is  called  the  "switched  trunking  mode". 

For  the  purposes  of  this  study,  the  ATM  option  is  assumed  to  be  operating  in  a 
switched  trunk  mode  (sophisticated  PABX  interconnection  model).  As  noted  earlier. 
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from  the  point  of  view  of  WAN  utilisation,  there  is  no  difference  between  the  two 
interconnection  methods  when  VoIP  is  being  used. 

3.2  VoIP 

3.2.1  H.323  Recommendations 

H323  is  an  umbrella  recommendation  from  the  International  Telecommunications 
Union  (ITU)  that  sets  standards  for  multimedia  communications  over  Local  Area 
Networks  (LAN)  that  do  not  provide  a  guaranteed  QoS  [3]  [4].  The  standard  is  broad  in 
scope  and  includes  both  stand-alone  devices  and  embedded  personal  computer 
technology  conducting  either  point-to-point  connections  or  multipoint  conferences. 
The  H.323  standard  provides  a  foundation  for  audio,  video  and  data  communications 
across  IP  based  networks.  By  complying  with  H.323,  multimedia  products  and 
applications  from  multiple  vendors  can  interoperate,  allowing  users  to  communicate 
without  concern  for  compatibility.  Fundamental  to  H.323  is  the  Real-Time 
Protocol/Control  Protocol  (RTP/RTCP)  of  the  Internet  Engineering  Task  Force  (IETF) 
[5]  used  for  carrying  packetised  real-time  traffic  over  an  IP  network.  Figure  1  shows  the 
RTF  packet  structure.  Typically  an  RTP  packet  has  a  payload  of  10  to  160  bytes  for 
applications  that  use  compressed  analog  to  digital  coding.  (Note  that  data  oriented 
commuiucations  and  computer  programmers  typically  use  the  term  byte  for  an  8  bit 
data  parcel.  By  contrast  the  telecommunications  term  for  8  bit  parcel  is  octet.  This 
report  will  use  both  terms  interchangeably.)  Analog  to  digital  coding  in  a  low  bit  rate 
voice  environment  is  normally  a  discontinuous  process.  It  entails  taking  a  short  sample 
(typically  tens  of  milliseconds)  of  digitised  voice  and  mathematically  processing  this 
waveform  data  into  a  frame  of  coded  voice  data.  For  a  coder  operating  at  a  typical  8 
kbps  and  sample  times  of  10  ms  the  frame  would  be  80  bits.  There  is  an  option  within 
RTP  to  carry  multiple  channel  frames  in  the  payload  to  improve  efficiency.  An 
approach  of  transporting  four  frames  in  one  payload  is  a  typical  commercial  option  but 
comes  at  the  price  of  additional  channel  latency  (i.e.  the  number  of  voice  frames  times 
the  frame  sample  period). 
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Figure  1  -  Real  Time  Services  over  IP 


An  architectural  overview  of  the  H.323  system  and  its  components  is  shown  in 
Figure  2.  H.225  describes  the  media  (audio  and  video)  stream  packetization,  media 
stream  synchronisation,  control  stream  packetization  and  control  message  formats  [6]. 
H.245  describes  the  procedures  and  messages  used  for  opening  and  closing  logical 
charmels  for  audio,  video  and  data,  capability  exchange,  mode  requests,  control  and 
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indications  [7].  These  are  the  recommendations  that  govern  the  operation  of  H.323 
equipment  and  the  communications  between  H.323  endpoints.  For  audio  coding,  G.711 
is  mandatory  while  G.722  and  G.729  are  optional.  In  this  report  we  will  evaluate  the 
performance  of  voice  traffic  over  IP  (and  ATM)  using  the  ITU-T  recommendation  G.729 
Armex  B  toll-quality  speech  coding  algorithm  also  known  as  the  Conjugated  Structure 
-  Algebraic  Code  Excited  Linear  Prediction  (CS-ACELP)  operating  at  a  fixed  rate  of  8 
kbps  [8]. 


Figure  2  -  Architectural  Overview  H.323  terminal  equipment 


Figure  3  shows  the  protocol  stack  for  H.323/H.225  logical  channels  and  other 
signalling.  The  transport,  network,  link  and  physical  layers  are  a  fimction  of  the  LAN 
and  are  outside  the  scope  of  H.323.  The  protocols  are  shown  in  parenthesis  and  the 
scope  of  this  report  is  shaded. 
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Figure  3  -  H.323  protocol  stack 


3.2.2  IP /UDP/RTP  Header  compression 

Since  RTF  was  published  as  an  IETF  Request  for  Comment  (RFC)  [9],  there  has  been  a 
growing  interest  in  using  RTF  as  one  step  towards  achieving  interoperability  among 
different  implementations  of  network  audio/video  applications.  However,  there  is  also 
concern  that  the  12-byte  RTF  header  is  too  large  an  overhead  for  typical  20-byte 
payloads  when  operating  over  low  speed  links.  Header  size  may  be  reduced  through 
compression  techniques  as  has  been  done  with  great  success  for  TCF  [10].  RTF  header 
compression  proposed  in  RFC  2508  [11]  reduces  the  IF/UDF/RTF  header  in  an  RTF 
data  packet  from  40  bytes  to  approximately  2  to  4  bytes  most  of  the  time  as  shown  in 
Figure  4.  This  big  gain  comes  from  the  observation  that  although  several  fields  change 
in  every  packet,  the  difference  from  packet  to  packet  is  often  constant  and  therefore  the 
second  order  difference  is  zero.  By  maintaining  both  the  uncompressed  header  and  the 
first  order  differences  in  the  session  state  shared  between  the  compressor  and 
decompressor,  all  that  must  be  commxmicated  is  an  indication  that  the  second  order 
difference  must  be  zero.  The  compressed  packet  carries  a  small  integer,  called  the 
session  context  identifier  or  CID  to  indicate  in  which  session  context  that  packet  should 
be  interpreted.  The  CID  is  effectively  an  identification  tag  for  the  voice  connection. 
Note  that  because  RTF  compression  removes  the  IF  header,  it  is  likely  to  be  negotiated 
and  employed  only  on  the  physical  link  between  routers.  The  IF  header  would  need  to 
be  reconstituted  in  order  to  permit  routing  of  the  IF  packet.  Alternatively,  layer  three 
packet  forwarding  based  on  the  CID  might  be  possible  between  co-operating  routers, 
nevertheless,  this  has  no  impact  on  the  wide  area  bandwidth  calculations  in  this  report. 
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Before  RTF  header  compression: 


bytes 


IP  UDP  RTP  Payload 


tap 

Channel  data 

20 

8 

12 

10  to  160 

After  RTP  header  compression: 
IP/UDP/RTP  header 


Payload 


1 

Channel  data 

s 

2-4 

10  to  160 

bytes 

Figure  4  -  IP/UDP/RTP  header  compression 


3.2.3  Packet  overhead  and  latency  tradeoff 

Increasing  the  number  of  frames  per  audio  packet  improves  the  bandwidth  utilisation 
and  decreases  network  packet  overhead.  However,  it  also  introduces  additional  delay 
to  the  audio  playback  since  a  packet  has  to  wait  for  all  the  audio  frames  to  be 
accumulated  before  sending  it  across.  Thus  a  tradeoff  exists  between  packet  overhead 
and  local  latency  for  audio  packet  transfer.  Figure  5  displays  the  manner  that 
efficiency,  ie  the  percentage  of  audio  data  versus  total  number  of  bits  in  the  RTP 
packet,  increases  as  packet  fill  latency  is  permitted  to  increase. 
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G729B  Efficiency  vs  Latency 


Figure  5  -  G729B  Efficiency  (%)  vs  Latency 


3.3  VTOA 

Voice  over  ATM  refers  to  the  transport  of  voice  and  voice-band  data  over  ATM.  In  this 
context  "voice"  refers  to  human  speech,  fax,  and  modem  data.  In  order  to  provide  a 
voice  service  over  an  ATM  network,  it  is  necessary  to  transport  the  voice  plus 
associated  signalling  information. 

3.3.1  The  Issues 

The  simplest  way  to  transport  the  voice  traffic  over  the  ATM  would  be  to  pass  the 
entire  inter-PABX  trunk  over  an  unstructured  constant  bit  rate  (CBR)  virtual  circuit 
using  the  ATM  adaptation  layer  AAL-1.  It  is  easy  to  implement  this  but  it  offers  no 
scope  for  any  bandwidth  economy  measures  to  reduce  the  impact  of  the  vmavoidable 
ATM  overheads  for  instance  by  not  transmitting  idle  channels.  In  order  to  achieve  this 
flexibility  in  bandwidth  allocation,  an  alternate  approach  would  have  each  voice 
connection  transferred  over  an  individual  ATM  connection.  While  this  would  be  quite 
feasible,  tibere  is  one  outstanding  problem.  With  low  rate  voice  coding  schemes  such  as 
G  729B  the  time  taken  to  fill  an  ATM  cell  leads  to  a  substantial  time  latency  (in  the 
order  of  50  ms). 
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3.3.2  AAL-2 

As  discussed  before,  we  have  conducted  this  examination  using  the  AAL-2  standard 
intended  for  low  bandwidth  real-time  variable  bit  rate  (VBR)  services.  The  AAL-2 
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Standard  is  being  developed  in  two  fora,  the  International  Telecommunications  Union 
as  ITU-T  Recommendation  1.363.2  [12]  and  1.366.2  [13],  as  well  as  the  ATM  Forum  as 
AF-VTOA-0013.000  [14].  Figure  6  illustrates  the  hierarchy  of  standards  cited  in  AF- 
VTOA-0013.000.  SSCS  refers  to  the  service  specific  convergence  sublayer  that  allows 
various  services  to  be  passed  over  the  common  part  sublayer  (CPS).  For  the  actual 
voice  data,  the  SSCS  does  not  add  any  additional  overheads.  These  are  incurred  only 
when  transferring  inband  (DTMF  tone  dialling)  signalling  or  fax  signalling  tones.  The 
interworking  facility  to  interworking  facility  (IWF-IWF)  common  channel  signalling 
(CCS)  can  be  transferred  over  either  AAL-5  (ie  treating  the  signalling  as  another  data 
channel)  or  over  the  AAL-2  cormection  to  which  it  is  associated. 


User 

Traffic 


User 

Traffic 


User 

Traffic 


Circuit  Mode 
Data  Services 


Nx64 
kbit/ s 


Inband 

PCM 

Compressed 

FAX 

Signalling 

Voice 

Voice 

Demod 

Frame  Mode 

IWF-IWF 

Voiceband  Services 

Data  Services 

CCS 

Figure  6  -  VTOA  (AAL-2)  Standards 

AAL-2  enables  sub-multiplexing  multiple  voice  channels,  perhaps  with  each  using 
a  different  voice  coding  standard,  into  a  single  ATM  connection.  This  makes  it  ideal 
for  use  between  voice  switches  (PABXs),  where  there  are  usually  many  simulataneous 
voice  calls  available  to  be  aggregated.  To  discriminate  between  each  of  the  calls,  voice 
frames  are  pre-pended  with  a  small  (three  octet)  header  (the  AAL-2  CPS  overhead).  To 
avoid  the  excessive  latency  problem,  AAL-2  employs  two  mechanisms.  First,  since  all 
the  PABX  interconnection  channels  share  the  one  ATM  cormection,  ATM  cells  are  filled 
at  the  aggregate  rate  of  all  the  active  charmels.  Second,  if  there  are  only  a  few  channels 
active  and  cells  are  being  delayed  waiting  for  additional  voice  frames  to  complete  the 
cell  fill,  the  AAL-2  process  can  dispatch  the  (partially  filled)  cell  at  the  expiry  of  a  timer 
rather  than  exceed  an  acceptable  latency  limit.  While  this  does  waste  some  bandwidth, 
it  only  happens  in  extremely  light  traffic  conditions.  Figure  7  shows  a  typical  voice 
packet  structure  segmented  into  ATM  cells  ready  for  transmission  over  the  ATM  path. 
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AAL-2 


Data  from  Chnl  3 


padding  or 
next  sequence 


ATM  cell  header  five  octets 


cell  payload  48  octets 


@  Data  Start  Pointer  one  octet 
I  I  AAL-2  header  three  octets 


Figure  7  -  AAL  2  over  ATM 


4.  VoIP  and  VTOA  Bandwidth  Requirements 


Annex  A  examines  the  demands  of  the  two  protocols.  By  comparison,  the  figure  for  the 
current  Parakeet  system  is  included.  This  TDM  system  provides  30  voice  channels  for 
512  kbps  consumed.  It  is  important  to  note  that  the  current  Parakeet  system  employs  a 
less  efficient  voice  coding  standard  called  continuously  variable  slope  delta 
modulation  (CVSD)  which  uses  16  kbps  per  channel  rather  than  the  8  kbps  of  G.729B. 
Also,  signalling  traffic  is  not  included  in  VoIP  and  VTOA  analysis  whereas  the 
Parakeet  TDM  stream  includes  one  16  kbps  channel  carrying  common  charmel 


signalling. 

Results  are  summarised  in  Figure  8  which  compares  the  VoIP  and  VTOA  options 
with  the  Parakeet  Eurocom  TDM  standard  (30  channels  totalling  512  kbps).  AAL-2  is 
clearly  the  most  economical  compared  with  RTP  with  header  compression  or  standard 
RTP  with  four  voice  frames  per  payload.  The  VoIP  solution  requires  both  header 
compression  and  multiple  voice  frames  per  payload  to  be  comparable  or  better  than 


V  1*1 

Note  that  four  voice  frames  per  RTP  payload  was  used  for  the  analysis  of  multiple 
frame  per  payload  as  it  appears  to  be  the  common  choice  within  industry 
implementations.  This  is  probably  a  compromise  between  efficiency  and  latency  driven 
by  the  demands  of  maximum  acceptable  consecutive  voice  frame  loss  specification  for 
G  729B.  Calculations  show  that  RTP  with  header  compression  and  two  voice  frames 
per  RTP  payload  is  almost  exactly  equal  to  AAL-2. 

The  bandwidth  demands  analysis  potentially  gives  a  slightly  optimistic  figure  for 
AAL2  for  three  or  fewer  channels  active  as  it  does  not  factor  in  the  transmission  of 
partially  empty  cells.  However,  the  figures  are  accurate  if  it  is  acceptable  to  have  up  to 
four  voice  frame  latency  during  low  voice  traffic  periods. 
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Figure  8  -  VoIP  VTOA  protocol  performance  comparison,  n=4 


5.  Signalling  Requirements 

The  demands  that  a  voice  telephony  system  places  on  a  network,  specifically  from  the 
voice  traffic  it  is  carrying,  were  examined  in  Section  4.  The  other  call  upon  network 
capacity  comes  from  the  need  for  signalling.  The  signalling  system  orchestrates  the 
actual  connection  of  users  as  well  as  housekeeping  tasks,  for  instance  the  distribution 
of  routing  information.  Again,  this  report  has  interest  in  the  bandwidth  requirements 
the  signalling  system  has  on  the  WAN.  However,  as  is  described  in  Armex  B,  the 
standards  in  this  arena  are,  in  parts,  still  being  developed.  Within  the  areas  that  are 
defined,  the  traffic  demands  are  significantly  less  than  those  of  the  voice  chaimel  or  are 
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unknown,  determined  by  the  network  scenario.  Accordingly,  the  signalling  load  will 
not  be  considered  in  this  report. 


6.  Parakeet  Reference  Network 


This  section  describes  a  reference  network  for  Parakeet  that  is  used  in  Appendix  C  to 
determine  voice  traffic  load  using  the  two  candidate  technologies.  The  network  carries 
applications  such  as  voice  and  general  computer  communications  in  a  fully 
cryptographically  secure  manner.  Circuit  switching  technology  is  central  to  the 
Parakeet  system  and  all  services  pass  through  the  circuit  switch.  The  circuit  switches 
are  interconnected  with  TDM  trunks.  Each  trunk  circuit  passes  through  an  on-line 
government  approved  encryption  device  to  provide  communications  security.  Trunks 
typically  run  at  512  kbps  and  the  rate  cannot  be  changed  without  disruption  to  ongoing 

calls. 

The  reference  network  is  shown  in  Figure  9  that  has  been  extracted  from  the 
Parakeet  specifications  [15].  For  the  purposes  of  the  specification,  each  node  is  given  a 
unique  identity.  The  'S'  prefix  denotes  a  small  circuit  switch  whilst  'L'  denotes  a  large 
circuit  switch  -  the  size  of  the  switch  is  largely  irrelevant  to  this  analysis.  While  the 
current  phase  of  Parakeet  will  field  only  six  ATM/IP  equipped  nodes,  our  analysis 
assumes  all  nodes  are  equipped  with  either  ATM  switches  or  IP  routers. 


Parakeet  Reference  Network 


Figure  9  -  Parakeet  Reference  Network 
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6.1  Traffic  Load  Calculation  Procedures 

Traffic  load  statistics  were  obtained  from  the  Parakeet  specifications  [15].  Once  traffic 
demands  between  the  nodes  have  been  allocated  to  pass  over  various  trunks,  the  load 
on  each  trunk  can  be  determined.  In  the  operational  network  the  routing  decision  will 
be  via  a  flood  search  routing  algorithm,  typically  this  results  in  a  shortest  path 
selection.  The  busy  hour  call  arrival  rate  for  ^e  busiest  trunk  link  was  then  used  in  a 
conventional  statistical  model  to  determine  the  probability  density  function  for  the 
number  of  active  channels  in  the  busy  hour  [16]. 

6.2  Results 

The  detailed  results  including  the  traffic  load  calculation  can  be  found  in  Appendix  C. 
Table  1  shows  the  number  of  calls  initiated  in  the  busy  hour  for  each  trunk. 


Link  Name 

Interconnect  nodes 

Number  of  calls  initiated  in 
the  busy  hour 

1 

SI /LI 

107.5 

2 

S2/L2 

130.0 

3 

S3/U 

125.0 

4 

S4/L4 

125.0 

5 

S5/L5 

107.5 

6 

L1/L8 

169.5 

7 

L2/L8 

208.3 

8 

L3/L9 

207.0 

9 

L4/L9 

207.0 

10 

L5/L12 

167.0 

11 

L12/L11 

239.5 

12 

L11/S7 

37.5 

13 

L10/L13 

85.0 

14 

L6/L7 

96.3 

15 

L6/S6 

70.4 

16 

L8/S6 

167.7 

17 

L8/L9 

239.2 

18 

L9/L11 

122.9 

19 

L6/L10 

156.0 

20 

L8/L10 

156.3 

21 

L9/L10 

111.5 

22 

LlO/Lll 

137.8 

Table  1  -  Network  Traffic  Loading 
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Figure  10  shows  the  probability  density  function  of  the  call  activity  on  the  busiest 
trunk.  This  shows  that  at  no  time  does  the  demand  on  the  busiest  trunk  exceed  25 
channels  of  the  30  possible.  The  average  number  of  channels  active  is  between  11  and 
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Figure  10  -  Probability  density  function  for  busy  hour  call  activity  on  the  busiest  trunk 


7,  Parakeet  Voice  via  VoIP  and  VTOA 


The  VoIP  and  VTOA  demands  on  Parakeet  transmission  capacity  has  been  calculated 
in  Appendix  D.  Peak  demand  (based  on  the  peak  of  25  active  channels)  on  the  busiest 
trunk  is  given  in  Table  2.  For  the  system  to  be  able  to  operate  without  undue  packet 
latency  or  packet  loss,  the  peak  demands  of  the  protocols  must  not  exceed  the  total  link 
rate.  The  expensive  nature  of  standard  VoIP  over  RTP  is  particularly  telling. 


TDM 

VOIP  Ifr/pkt 

VOIP  4 
fr/pkt 

VOIPl 

fr/pkt 

compressed 

VOIP  4 
fr/pkt 
compressed 

AAL-2 

512 

1100.0 

425.0 

380.0 

245.0 

293.2 

Fable  2  -  Peak  Bandwidth  Demands  (kbps) 


To  calculate  an  average  bandwidth,  the  bandwidth  demands  of  each  protocol  is 
weighted  by  the  probability  density  function  of  the  number  of  active  channels.  This 
provides  a  figure  that  indicates  the  average  bandwidth  being  used  by  the  voice  system 
during  the  busy  hour  on  the  busiest  trunk.  The  difference  between  this  figure  and  the 
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total  link  rate  indicates  how  much  capacity  would  be  available  for  non-real  time 
communications.  Table  3  shows  the  results  for  the  options  under  examination. 


TDM 

VOIP  Ifr/pkt 

VOIP  4 
fr/pkt 

VOIPl 

fr/pkt 

compressed 

VOIP  4 
fr/pkt 
compressed 

AAL-2 

512 

526.9 

203.6 

182.0 

117.4 

152.2 

Table  3  -Average  Bandwidth  Demands  (kbps) 


8.  Discussion  and  Conclusions 

In  this  section  we  highlight  some  of  the  key  contributions  made  in  this  report.  The 
analysis  has  focussed  on  the  bandwidth  demands  of  the  different  approaches.  Further 
work  will  be  required  to  analyse  the  other  factors  (for  instance  network  delays)  that 
will  also  contribute  to  determining  the  feasibility  of  these  approaches  in  the  tactical 
domain. 

8.1  RTPAJDP/IP  Header  Compression 

Protocol  header  compression  has  been  an  active  research  area  for  the  past  couple  of 
years  especially  after  the  maturity  of  the  protocols  and  standards  that  drive  audio  and 
video  streaming  over  the  Internet.  Any  use  of  IP  as  a  total  WAN  solution  for  voice 
services  must  implement  RTP,  UDP  and  IP  header  compression  to  be  feasible  in  the 
tactical  domain. 

8.2  Bandwidth  Savings 

The  average  bandwidth  demands  used  by  the  voice  system  during  the  busy  hour  on 
the  busiest  trunk  indicate  that  VTOA  (AAL-2)  and  VoIP  with  packet  header 
compression  are  certainly  promising  solutions.  If  header  compression  is  available  and 
the  use  of  four  frames  per  packet  (40  ms)  does  not  lead  to  link  delays  unacceptable  to 
users,  VoIP  can  provide  a  slightly  more  economical  solution  than  VTOA.  Regardless  of 
which  approach  is  adopted,  significant  capacity  can  be  released  for  non-real  time 
communications. 
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Appendix  A:  Network  Load  from  Voice 


ATM  parameters  in  bits 

24  AAL-2  frame  header 
80  AAL-2  frame  size 
0.28  equivalent  ATM  cells 
10  frame  latency  (ms) 

IP  parameters  in  bits 

40  PPP  header  -  5  bytes 

160  IP  header  -  20  bytes 

64  UDP  header  -  8  bytes 

96  RTP  header  -  12  bytes 

8  G.729  codec  bit  rate  -  kbits/sec 

10  G.729  frame  period  -  msec 

80  G.729  data  size  per  frame  -  bytes 

4  Number  of  frames  per  packet 

32  IP/UDP/RTP  compressed  header  -  4  bytes 

Voice  over  ATM 

Because  of  the  offset  pointer,  the  number  of  octets  per  cell  is  47. 

The  overall  bit  rate  for  voice  over  ATM  using  AAL-2  and  a  G729  speech  coder  (8kbps/sec)  is 
given  by, 

(53/47)*Number_of_channels*((8/G279_frame_size)*(AAL2_header+  G729_frame_size)) 

Voice  over  IP 

The  overall  bit  rate  for  voice  over  IP  is  given  by, 

]  frame/packet: 

Number_of_channels*(PPP_header+IP_header+UDP_header+RTP_header+G729_frame_size)/ 
G7 29_frame_period 

n  frames/packet: 

Number_of_channels*(PPP_header+IP_header+UDP_header+RTP_header+(n_frames_per_pkt 

*G729_frame_size))/(G729_frame_period*n_frames_per_pkt) 

I  frame/packet  (RTP/UDP/IP  header  compression): 

Number_of_channels*(PPP_header+IP_UDP_RTP_compressed_header+G729_frame_size)/(G 

729_frame_period) 

n  frames/packet  (RTP/UDP/IP  header  compression): 

Number_of_channel  s  *(PPP_header+IP_UDP_RTP_compressed_header-i-(n_frames_per_pkt  *  G 
729_frame_size))/(G729_frame_period*n_frames_per_pkt) 
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Channels 
active  (N) 


Bandwidth  demands  for  given  number  of 


VOIP- 

VOIP- 

1  fr/pkt 

4  fr/pkt 

0.0 

0.0 

44.0 

17.0 

88.0 

34.0 

132.0 

51.0 

176.0 

68.0 

220.0 

85.0 

264.0 

102.0 

308.0 

119.0 

352.0 

136.0 

396.0 

153.0 

440.0 

170.0 

484.0 

187.0 

528.0 

204.0 

572.0 

221.0 

616.0 

238.0 

660.0 

255.0 

704.0 

272.0 

748.0 

289.0 

792.0 

306.0 

836.0 

323.0 

880.0 

340.0 

924.0 

357.0 

968.0 

374.0 

1012.0 

391.0 

1056.0 

408.0 

1100.0 

425.0 

1144.0 

442.0 

1188.0 

459.0 

1232.0 

476.0 

1276.0 

493.0 

0.0 

0.0 

0.0 

15.2 

9.8 

11.7 

30.4 

19.6 

23.5 

45.6 

29.4 

35.2 

60.8 

39.2 

46.9 

76.0 

49.0 

58.6 

91.2 

58.8 

70.4 

106.4 

68.6 

82.1 

121.6 

78.4 

93.8 

136.8 

88.2 

105.5 

152.0 

98.0 

117.3 

167.2 

107.8 

129.0 

182.4 

117.6 

140.7 

197.6 

127.4 

152.5 

212.8 

137.2 

164.2 

228.0 

147.0 

175.9 

243.2 

156.8 

187.6 

258.4 

166.6 

199.4 

273.6 

176.4 

211.1 

288.8 

186.2 

222.8 

304.0 

196.0 

234.6 

319.2 

205.8 

246.3 

334.4 

215.6 

258.0 

349.6 

225.4 

269.7 

364.8 

235.2 

281.5 

380.0 

245.0 

293.2 

395.2 

254.8 

304.9 

410.4 

264.6 

316.6 

425.6 

274.4 

328.4 

440.8 

284.2 

340.1 
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Appendix  B:  Signalling  Requirement 


B.l  VOIP 

H.323  defines  two  basic  models  for  call  signalling.  The  first  model  is  direct  call 
signalling,  where  signalling  takes  place  between  the  endpoints  (terminals).  The  second 
model  is  gatekeeper  routed  call  signalling,  where  the  gatekeeper  relays  all  call 
signalling  between  endpoints.  Call  signalling  procedures  are  based  on  Q.931  as  tailored 
by  H.225.0.  There  are  three  signalling  scenarios  that  are  derived  from  the  basic  models: 

•  endpoint  1  -  endpoint  2  communications  (direct  model). 

•  endpoint  1  -  gatekeeper  -  endpoint  2  communications  (gatekeeper  mediated). 
Negotiating  a  connection  through  a  common  gatekeeper  would  be  typically  only 
appropriate  when  both  endpoints  were  on  the  same  LAN  and  hence  will  not  be 
considered  further  in  this  report. 

•  endpoint  1  -  gatekeeper  1  -  gatekeeper  2  -  endpoint  2  communications  (gatekeeper 
mediated).  Such  scenario  would  see  a  gatekeeper  on  each  LAN  acting  as  the 
controlling  function  usually  seen  in  the  PABX  of  traditional  voice  networks. 

Figure  11  shows  the  steps  involved  in  establishing  a  call  for  scenario  1. 

Endpoint  1  Endpoint  2 


Table  4  illustrates  the  size  of  typical  success,  failure  and  status  messages  (in  bytes) 
traversing  the  WAN.  For  example,  in  a  successful  call  setup,  the  maximum  amount  of 
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signalling  information  is  about  691  bytes.  Note  that  the  maximum  values  were 
obtained  when  the  mandatory  fields  were  completely  utilised  A  typical  message 
structure  is  shown  in  Figure  12.  For  a  nominal  3  minute  call  duration  this  signalling 
load  is  minimal  (averaging  30  bps). 


Message  Size 
(bytes) 

Success 

Failure 

Status 

Minimum 

45 

43 

17 

Maximum 

691 

558 

45 

Table  4  -  Message  Size  in  bytes  for  success,  failure  and  status  messages 


Setup  Message 

Setup-UUIE : 

•  Protocol  Identifier 

•  H245  Address 

•  Source  Address 

•  Source  Info 

•  Dest  Address 

•  Dest  Call  Signal  Address 

•  Active  MC 

•  Conference  ID 

•  Conference  Goal 

•  Call  Services 

•  Call  Type 

•  ... 

Figure  12  -  Setup  messsage  structure  in  bytes,  Mfor  mandatory,  Ofor  optional 


Information  element 

status 

Length 

Protocol  discriminator 

M 

1 

Call  reference 

M 

3 

Message  type 

M 

1 

Sending  complete 

O 

1 

Bearer  capability 

M 

5-6 

Display 

O 

2-82 

Keypad  facility 

O 

2-34 

Signal 

O 

2-3 

Calling  party  number 

0 

2-131 

Called  party  number 

o 

2-131 

User-to-User 

M 

2-131 

The  final  scenario  is  of  particular  interest  to  us.  To  date  gatekeeper  to  gatekeeper 
communications  have  not  yet  been  standardised.  The  draft  standard,  [17]  discusses  a 
framework  for  a  peer  gatekeeper  routing  protocol  (PGRP)  that  supports  the  exchange 
of  information  among  gatekeepers  about  elements  in  their  respective  zones  (see  Figure 
13).  PGRP  provides  a  mechanism  by  which  gatekeepers  may  acquire  knowledge  of 
both  static  and  dynamic  information  from  other  zones.  At  each  level  of  the  hierarchy, 
information  is  collated  and  a  summary  of  this  information  is  then  distributed. 
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Figure  13  -  Scenario  3  -  endpoint  -  gatekeeper  -  gatekeeper  -  endpoint  communications 


After  call  setup  is  complete,  all  communications  between  endpoints  take  place  over 
logical  channels  that  are  opened  using  the  procedures  of  H.245.  There  is  only  one 
logical  channel  for  control  and  separate  logical  channels  for  each  media  type.  In 
addition  to  the  logical  channels  opened  for  the  actual  audio  or  video  media,  a  separate 
logical  channel  for  the  RTCP  must  be  opened  to  provide  a  feedback  mechanism  for 
QoS  to  the  source  media. 

B.2  VTOA 

Signalling  standards  between  voice  circuit  switches  are  covered  by  a  number  of 
techniques  based  on  ITU  standard  Q.931  including  Signalling  System  7,  Digital  Private 
Network  Signalling  System  (DPNSS)  and  the  ETSI  QSIG  system.  Note  that  QSIG  is 
now  being  standardised  as  Private  Signalling  System  no.  1  (PSSl)  by  ISO/IEC  in 
ISO/IEC  11572.  These  systems  typically  employ  one  of  the  voice  channel  time  slots  to 
provide  the  signalling  on  a  common  charmel  between  the  two  switches.  If  a  network  of 
voice  switches  is  simply  interconnected  over  an  ATM  network,  then  it  is  relatively 
simple  to  transfer  the  common  channel  signalling  as  a  constant  bit  rate  64  kbps  service. 

For  this  report,  the  preferred  configuration  sees  the  ATM  network  acting  as  a 
virtual  voice  switch.  In  this  case,  the  common  channel  signalling  is  terminated  and 
interpreted  in  the  IWF.  The  signalling  that  passes  between  the  IWF  and  the  local  voice 
switch  comprises  two  fundamental  elements:  basic  services  such  as  call 
establishment/tear  down  and  supplementary  services  such  as  call  redirection.  The 
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ATM  Forum  [14]  specifies  that  IWFs  should  be  able  to  interchange  PSSl  messages  via 
either  AAL-5  or  AAL-2  data  channels.  This  report  has  not  attempted  to  examine  the 
traffic  load  generated  by  PSSl  over  ATM.  Apart  from  the  call  setup/ tear  down  which 
might  be  analysed,  there  are  a  number  of  scenario  dependent  elements  which  would  be 
difficult  to  itemise  such  as  signalling  to  establish  switched  virtual  circuits  between 
ATM  elements  versus  provision  via  permanent  virtual  circuits,  sharing  of  routing 
information  etc.  What  is  standardised  in  AAL-2  [12]  is  the  interchange  to 
establish /remove  voice  connections  in  the  AAL-2  structure.  These  are  passed  using  the 
AAL-2  protocol  itself  using  a  logical  channel  associated  with  each  voice  channel.  The 
data  elements  are  very  small.  For  instance  the  charmel  assignment  request  message  has 
mandatory  elements  totalling  only  3  octets. 
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Appendix  C:  Voice  Traffic  Model 


Traffic  Statistics  provided  by  the  Parakeet  Specification  (per  day  cal!  initiation) 


Src\ 

Des 

t 

SI 

S2 

S3 

S4 

S5 

S6 

S7 

LI 

L2 

L3 

L4 

L5 

L6 

L7 

L8 

L9 

LIO 

Lll 

L12 

L13 

Tot 

SI 

165 

20 

■ 

■ 

■ 

40 

40 

10 

■ 

■ 

■ 

10 

5 

30 

20 

30 

m 

S2 

20 

165 

20 

■ 

■ 

40 

20 

40 

20 

■ 

■ 

10 

5 

30 

20 

30 

S3 

20 

165 

20 

40 

■ 

■ 

20 

40 

20 

10 

5 

30 

20 

30 

420 

S4 

■ 

■ 

20 

165 

20 

40 

■ 

■ 

■ 

20 

40 

20 

10 

5 

30 

20 

30 

420 

S5 

■ 

■ 

■ 

20 

165 

40 

■ 

■ 

■ 

■ 

20 

40 

10 

5 

30 

20 

30 

380 

S6 

40 

40 

40 

40 

40 

185 

35 

10 

10 

10 

10 

10 

30 

35 

■ 

■ 

■ 

535 

S7 

■ 

■ 

■ 

■ 

■ 

35 

165 

■ 

■ 

■ 

■ 

■ 

10 

5 

■ 

■ 

■ 

35 

250 

LI 

30 

20 

■ 

■ 

■ 

10 

95 

35 

■ 

■ 

■ 

10 

10 

10 

20 

20 

15 

H 

288 

L2 

10 

30 

■ 

■ 

■ 

10 

35 

95 

35 

■ 

■ 

10 

5 

10 

20 

20 

15 

13 

308 

L3 

10 

30 

■ 

■ 

10 

■ 

■ 

35 

95 

35 

10 

10 

10 

20 

20 

15 

13 

313 

L4 

■ 

■ 

10 

30 

10 

■ 

■ 

■ 

35 

95 

35 

10 

10 

10 

20 

20 

15 

13 

313 

L5 

■ 

■ 

■ 

10 

30 

10 

■ 

■ 

■ 

■ 

35 

95 

10 

10 

10 

20 

20 

15 

13 

278 

L6 

10 

10 

10 

10 

10 

30 

10 

10 

10 

10 

10 

185 

35 

15 

15 

15 

35 

25 

455 

L7 

10 

10 

10 

10 

10 

30 

10 

10 

10 

10 

10 

30 

160 

■ 

■ 

■ 

■ 

30 

370 

L8 

25 

25 

25 

25 

25 

10 

20 

20 

20 

20 

20 

15 

10 

150 

40 

40 

15 

m 

520 

L9 

25 

25 

25 

25 

25 

25 

20 

20 

20 

20 

20 

25 

40 

150 

40 

15 

II 

535 

LIO 

25 

25 

25 

25 

25 

25 

20 

20 

20 

20 

20 

25 

40 

40 

150 

15 

m 

535 

Lll 

■ 

■ 

■ 

■ 

■ 

■ 

30 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

165 

m 

195 

L12 

15 

15 

15 

15 

15 

15 

5 

5 

5 

5 

5 

10 

10 

10 

■ 

■ 

160 

15 

320 

L13 

15 

15 

15 

15 

15 

15 

5 

5 

5 

5 

5 

10 

10 

10 

10 

15 

160 

330 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

0 

Tot 

als 

390 

430 

410 

410 

380 

620 

230 

290 

335 

345 

345 

290 

420 

335 

465 

465 

505 

200 

360 

330 

The  Parakeet  Specification  calls  for  the  Busy  Hour  to  have  four  times  the  average 
hourly  number  of  call  initiations.  The  source  to  destination  determines  (via  shortest 
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path)  the  links  that  each  call  initiation  is  to  traverse.  One  can  then  calculate  the  number 
of  calls  processed  in  the  busy  hour  on  the  busiest  link. 


Link  Utilisation 


Link  Name 

Interconnect  nodes 

Number  of  calls  initiated  in 
the  busy  hour 

1 

Sl/Ll 

107.5 

2 

S2/L2 

130.0 

3 

S3/L3 

125.0 

4 

S4/L4 

125.0 

5 

S5/L5 

107.5 

6 

L1/L8 

169.5 

7 

L2/L8 

208.3 

8 

L3/L9 

207.0 

9 

L4/L9 

207.0 

10 

L5/L12 

167.0 

11 

L12/L11 

239.5 

12 

L11/S7 

37.5 

13 

L10/L13 

85.0 

14 

L6/L7 

96.3 

15 

L6/S6 

70.4 

16 

L8/S6 

167.7 

17 

L8/L9 

239.2 

18 

L9/L11 

122.9 

19 

L6/L10 

156.0 

20 

L8/L10 

156.3 

21 

L9/L10 

111.5 

22 

LlO/Lll 

137.8 

The  following  procedures  are  followed  to  determine  the  channel  utilisation 

30  -  number  of  channels  (K) 

239.5  -  mean  arrival  rate  per  hour 
3.991667  -  mean  arrival  rate  per  minute,  A 
3  -  mean  call  holding  time  in  minutes 
0.333333  '  mean  service  rate  per  minute,  fi 
11.975  -  utilization  factor  for  each  channel,  p 
0.399167  -  utilization  factor  for  system,  p 
6.3E-06  -  probability  of  no  calls,  P(0} 


The  following  formulas  were  used  to  compute  the  measures  of  performance  [16]: 
Utilisation  factor  of  the  entire  system,  p  : 

^  K  Kii 
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Assuming  that  X<K^  (a  necessary  condition  to  avoid  an  explosive  queue), 
The  probability  of  no  calls,  P(0): 


P(0)  = 


1 


The  probability  of  N  channels  being  in  use,  P(N): 

P(N)  =  P(0)^,ifN<K 

P(N)  =  if  N>  K 

Kl 


Channel  Utilisation 


Channels,  N 

P(N) 

Cum  Dist 

0 

0.000 

0.000 

1 

0.000 

0.000 

2 

0.000 

0.001 

3 

0.002 

0.002 

4 

0.005 

0.008 

5 

0.013 

0.021 

6 

0.026 

0.046 

7 

0.044 

0.091 

8 

0.066 

0.157 

9 

0.088 

0.245 

10 

0.105 

0.350 

11 

0.115 

0.464 

12 

0.114 

0.579 

13 

0.105 

0.684 

14 

0.090 

0.774 

15 

0.072 

0.846 

16 

0.054 

0.900 

17 

0.038 

0.938 

18 

0.025 

0.963 

19 

0.016 

0.979 

20 

0.010 

0.989 

21 

0.005 

0.994 

22 

0.003 

0.997 

23 

0.002 

0.999 

24 

0.001 

0.999 

25 

0.000 

1.000 

26 

0.000 

1.000 

27 

0.000 

1.000 

28 

0.000 

1.000 

29 

0.000 

1.000 

30 

0.000 

1.000 
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Appendix  D:  VoIP  and  VTOA  Demands  on  Parakeet 

Transmission 


Table  applies  the  traffic  analysis  to  the  bandwidth  demands. 


chn  Bandwidth  demands  for  given  P(N)  Contribution  to  Average 

number  of  active  channels  (N)  Bandwidth  demand 


TDM 

VOIP- 
1  fr/pkt 

VOIP- 
4  fr/pkt 

VOIP- 
1  fr/pkt 
compr 

VOIP- 
4  fr/pkt 
compr 

AAL- 

2 

VOIP- 
1  fr/pkt 

VOIP- 
4  fr/pkt 

VOIP- 
1  fr/pkt 
compr 

VOIP- 
4  fr/pkt 
compr 

AAL-2 

0 

512 

0.0 

0.0 

0.0 

0.0 

0.0 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

1 

512 

44.0 

17.0 

15.2 

9.8 

11.7 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

2 

512 

88.0 

34.0 

30.4 

19.6 

23.5 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

3 

512 

132.0 

51.0 

45.6 

29.4 

35.2 

0.002 

0.2 

0.1 

0.1 

0.1 

0.1 

4 

512 

176.0 

68.0 

60.8 

39.2 

46.9 

0.005 

1.0 

0.4 

0.3 

0.2 

0.3 

5 

512 

220.0 

85.0 

76.0 

49.0 

58.6 

0.013 

2.8 

1.1 

1.0 

0.6 

0.8 

6 

512 

264.0 

102.0 

91.2 

58.8 

70.4 

0.026 

6.8 

2.6 

2.4 

1.5 

1.8 

7 

512 

308.0 

119.0 

106.4 

68.6 

82.1 

0.044 

13.6 

5.3 

4.7 

3.0 

3.6 

8 

512 

352.0 

136.0 

121.6 

78.4 

93.8 

0.066 

23.3 

9.0 

8.0 

5.2 

6.2 

9 

512 

396.0 

153.0 

136.8 

88.2 

105.5 

0.088 

34.8 

13.5 

12.0 

7.8 

9.3 

10 

512 

440.0 

170.0 

152.0 

98.0 

117.3 

0.105 

46.3 

17.9 

16.0 

10.3 

12.3 

11 

512 

484.0 

187.0 

167.2 

107.8 

129.0 

0.115 

55.5 

21.4 

19.2 

12.4 

14.8 

12 

512 

528.0 

204.0 

182.4 

117.6 

140.7 

0.114 

60.4 

23.3 

20.9 

13.4 

16.1 

13 

512 

572.0 

221.0 

197.6 

127.4 

152.5 

0.105 

60.3 

23.3 

20.8 

13.4 

16.1 

14 

512 

616.0 

238.0 

212.8 

137.2 

164.2 

0.090 

55.5 

21.4 

19.2 

12.4 

14.8 

15 

512 

660.0 

255.0 

228.0 

147.0 

175.9 

0.072 

47.5 

18.3 

16.4 

10.6 

12.7 

16 

512 

704.0 

272.0 

243.2 

156.8 

187.6 

0.054 

37.9 

14.6 

13.1 

8.4 

10.1 

17 

512 

748.0 

289.0 

258.4 

166.6 

199.4 

0.038 

28.4 

11.0 

9.8 

6.3 

7.6 

18 

512 

792.0 

306.0 

273.6 

176.4 

211.1 

0.025 

20.0 

7.7 

6.9 

4.5 

5.3 

19 

512 

836.0 

323.0 

288.8 

186.2 

222.8 

0.016 

13.3 

5.1 

4.6 

3.0 

3.5 

20 

512 

880.0 

340.0 

304.0 

196.0 

234.6 

0.010 

8.4 

3.2 

2.9 

1.9 

2.2 

21 

512 

924.0 

357.0 

319.2 

205.8 

246.3 

0.005 

5.0 

1.9 

1.7 

1.1 

1.3 

22 

512 

968.0 

374.0 

334.4 

215.6 

258.0 

0.003 

2.9 

1.1 

1.0 

0.6 

0.8 

23 

512 

1012.0 

391.0 

349.6 

225.4 

269.7 

0.002 

1.6 

0.6 

0.5 

0.3 

0.4 

24 

512 

1056.0 

408.0 

364.8 

235.2 

281.5 

0.001 

0.8 

0.3 

0.3 

0.2 

0.2 

25 

512 

1100.0 

425.0 

380.0 

245.0 

293.2 

0.000 

0.4 

0.2 

0.1 

0.1 

0.1 

26 

512 

1144.0 

442.0 

395.2 

254.8 

304.9 

0.000 

0.2 

0.1 

0.1 

0.0 

0.1 

27 

512 

1188.0 

459.0 

410.4 

264.6 

316.6 

0.000 

0.1 

0.0 

0.0 

0.0 

0.0 

28 

512 

1232.0 

476.0 

425.6 

274.4 

328.4 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

29 

512 

1276.0 

493.0 

440.8 

284.2 

340.1 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

30 

512 

1320.0 

510.0 

456.0 

294.0 

351.8 

0.000 

0.0 

0.0 

0.0 

0.0 

0.0 

Av 

e 

512 

526.9 

203.6 

182.0 

117.4 

152.2 
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